This invention relates to communication of digital data over a wireless transmission medium.
As shown in FIG. 1, a wireless radio network 10, for example, may use the High Data Rate (HDR) protocol. HDR is an emerging mobile wireless access technology that enables personal broadband Internet services that can be accessed from anywhere, anytime. (See P. Bender, et al., “CDMA/HDR: A Bandwidth-Efficient High-Speed Wireless Data Service for Nomadic Users”, IEEE Communications Magazine, July 2000; and 3GPP2, “Draft Baseline Text for 1xEV-DO,” Aug. 21, 2000, developed by Qualcomm Inc, both incorporated here by reference).
HDR is a new air interface optimized for IP packet data services, which can deliver a shared forward link transmission rate of up to 2.46 Mbits/s per sector using only (1×) 1.25 MHz of spectrum. Compatible with CDMA2000 radio access (see TIA/EIA/IS-2001, “Interoperability Specification (IOS) for CDMA2000 Network Access Interfaces,” May 2000, by reference) and wireless IP network interfaces (see TIA/EIA/TSB-115, “Wireless IP Architecture Based on IETF Protocols,” Jun. 6, 2000, and TIA/EIA/IS-835, “Wireless IP Network Standard,” 3rd Generation Partnership Project 2 (3GPP2), Version 1.0, Jul. 14, 2000, both incorporated here by reference), HDR networks can be built entirely on IP technologies, all the way from the mobile Access Terminal (AT) to the global Internet, thus taking advantage of the scalability and low-cost of IP networks. HDR is being adopted by 3GPP2 as a new standard in the CDMA2000 family, an EVolution of the current 1xRTT standard for high-speed data-only (DO) services, formally referred to as 1xEV-DO.
In recent years, growth of IP networks has created a growing interest by network operators to offer differentiated service tiers that provide different levels of quality of service (QoS) to different users (user-level QoS), and to provide a differentiated treatment of different application flows of the same user (application-level QoS). Providing QoS on wireless access networks such as HDR is especially important to operators, because bandwidth is precious and effective management of that bandwidth is important.
Progress has been made in recent years in developing the underlying technologies for enabling QoS over IP networks (See Ross Callon, A Viswanathan, and E. Rosen, “Multiprotocol Label Switching Architecture,” IETF Internet Draft, August 2000, and S. Blake, et al., “An Architecture for Differentiated Services,” IETF RFC 2475, December 1998, incorporated by reference.)
However, mobile wireless networks introduce additional complexities in QoS delivery because of mobility and the variable bit rate nature of wireless transmissions.
The HDR Access Network Architecture:
Here the Access Terminal (AT) may be a laptop 12, a Personal Digital Assistant (PDA) 14 or a dual-mode voice/data handset, with built-in HDR support (not shown).
An HDR Radio Access Network (RAN) 10, which may cover a large service area of an operator, consists of one or more Access SubNetworks (ASN's) 16 each anchored by a Radio Node Controller (RNC) 18 communicating with several Radio Nodes (RN's) 20 over a private or public IP backhaul network 22. Each RN may support multiple sectors and each sector covers a certain cell area around the RN.
Each ASN is connected over a public or private IP network 24 to one or more Packet Data Serving Node's (PDSN's) 26. A PDSN can be viewed as an edge router that supports mobility; it maintains link layer connectivity to AT's through the RAN.
Data Path Over the HDR RAN in the Forward Direction:
The PDSN receives IP packets 30 from the Internet, identifies the user to which each packet is destined, determines the Class of Service (CoS) corresponding to each packet, and then encapsulates each packet into a tunnel packet indicating in the header of the tunnel packet the user and the CoS information.
The RNC extracts the payload data from the tunnel packets 32 arriving from the PDSN, and constructs from the payload data HDR application layer frames. Those HDR application layer frames are then encapsulated into tunnel packets 34 and sent towards the RN. The header of a tunnel packet indicates the CoS associated with that packet.
The RN receives the tunnel packets from the RNC, determines the CoS associated with each packet, retrieves the HDR application layer payload and constructs the HDR Physical Layer packets 36 to be transmitted to the AT's over the air-link.
HDR Protocol Operation:
When an AT is first powered-on inside the coverage area of an ASN, it typically opens a new HDR session with the RAN. An HDR session can be viewed as an “always-on” state between an AT and the RAN, which stays alive as long as the AT is powered on and remains in the coverage area of the RAN. When an AT has an open session, it can exchange HDR control messages with the RAN, but to exchange user data with the PDSN and beyond, it needs to establish a connection. Once connected, AT's consume air link resources, but only when they are actually exchanging data with the network. Connections are initiated by the AT by sending a Connection Request message to an RNC that makes a decision to accept or deny the request. In addition to Connection Admission Control, the RNC is primarily responsible for address/session management, RAN authentication, handling handoff events and for running the HDR application layer protocols.
Each RN consists of multiple sectors and each sector has a Forward Link Transmitter (FLT) and a Reverse Link Receiver (RLR) handling all air link and related protocol processing.
The FLT receives from the network interface variable-length HDR Application Layer frames from which it constructs MAC Layer frames. Forward link MAC Layer frames are always 128 bytes. The FLT combines MAC Layer frames that belong to the same AT in physical layer packets of length L=128, 256, 384 or 512 bytes, where the actual length depends on the bit rate, and then encodes, modulates and transmits them over the air link in a TDM fashion at a constant transmit power. Forward traffic packets are transmitted at variable bit rates that range from 38.4 kbit/s to 2.46 Mbit/s, specifically at rates k×38.4 kbit/s, where k=1, 2, 4, 8, 16, 24, 32, 48 or 64. In general, longer packets are used at higher bit rates. Variable-rate transmission is a key feature of HDR, as it allows the system to serve users at the highest rate that their channel condition would allow.
The basic building block of the HDR physical layer frame structure is a time slot of duration 1/600=1.67 ms. Time slots can be viewed as the basic shared transmission resource on the air link. All packets are carried in an integral number, N, of time slots, where N is 1, 2, 4, 8 or 16. For a given bit rate of k×38.4 kbit/s and packet size L, N can be easily determined: N=L/(8×k).
The transmission rate of a forward traffic packet is dynamically determined by the receiving AT's, which continuously estimate the signal-to-interference ratio (SIR) using pilot transmissions received from all sectors in their active list and report back, once every time slot, their individual bit rate requests to the ASN. In HDR, the bit rate request of user i at time t is referred to as the DRCi(t). It is important to note that a sector transmitting a packet to a user has to transmit at the bit rate selected by the AT, thus rate selection is entirely under the control of the AT. The sector can delay the transmission of a packet, but it cannot transmit at a rate that differs from the requested rate.
In every time slot, the system first checks to see if the next slot is empty (that is, if no packet transmission is continuing). If it is, it asks the scheduler to select the next packet for transmission, it encodes/modulates that packet and starts transmitting it in the empty slot. One scheduler, known as the Qualcomm algorithm, is described in A. Jalali, R. Padovani, R. Pankaj, “Data Throughput of CDMA-HDR a High Efficiency-High Data Rate Personal Communication Wireless System”, Vehicular Technology Conference VCT2000 Proceedings, Volume 3, May 2000.
As shown in FIG. 2, in the Qualcomm algorithm, all users (represented by respective user queues 42) are treated equally by the RN. Each sector, in every time slot t, measures and updates the average (over an appropriate time window) data rate Ri(t) for every active user i. Whenever the scheduler 44 finds an empty time slot, it chooses for transmission the packet that belongs to the user who has the highest ratio of: DRCi(t)/Ri(t) 46, where DRCi(t) is the most recent requested rate of the i'th user.
Differentiated Services (DiffServ) Quality of Service (QoS)
QoS at a network node is the ability of that node to provide some level of assurance that the service requirements of the traversing traffic can be satisfied. To provide QoS, network nodes must manage their available link bandwidth according to application demands and network management settings. QoS parameters mainly include: bandwidth, delay, delay jitter and loss.
DiffServ is an architecture (among other architectures) defined by the Internet Engineering Task Force (IETF) in order to provide QoS. In the DiffServ model, traffic entering a network is classified and possibly conditioned at the boundaries of the network, before being assigned to different Behavior Aggregates (BA). Each behavior aggregate is identified by a single DiffServ Code Point (DSCP), a re-defined layout of the IPv4 TOS byte. Within the core of the network, packets are forwarded according to the Per Hop Behavior (PHB) associated with the BA represented by the DSCP. Hence, several service classes can be differentiated on the basis of the DSCP field value by applying its forwarding behavior or PHB. At the ingress of a DiffServ network domain, packets are classified, policed and possibly shaped. The classification, policing and shaping rules used at the ingress routers, as well as the buffering space amount needed for these operations, derives from Service Level Agreements (SLA) negotiated between the network domains across which the data packets travel end-to-end. Two differentiated services have been proposed, the first being Expedited Forwarding (EF) and the second being Assured Forwarding (AF).
The EF DiffServ class is intended for real-time traffic which requires low loss, low latency, low jitter and guaranteed bandwidth. This implies that a DiffServ node that supports this service class must allocate a certain amount of forwarding resources (buffer space and bandwidth) for this traffic in order to ensure that such traffic encounters very small queues when exiting the node, and that the forwarding performance of EF traffic is independent of the load intensity of lower traffic classes.
The AF DiffServ class is intended to serve more elastic traffic that requires bandwidth guarantees. The IETF defines four AF classes where each AF class in a supporting DiffServ node is allocated fixed amounts of forwarding resources. Each of the four AF classes supports three levels of packet drop precedence. The drop precedence with which a packet is marked, indicates the relative importance of that packet when the DiffServ node is congested.
IP packets exchanged between the mobile user and the PDSN travel across the HDR RAN. According to DiffServ, the RN and the RNC must implement, in both the forward and the reverse directions, the PHB associated with an IP packet based on the value of the DSCP field of that packet. The PHB includes among other components, discarding, scheduling and marking IP packets.